Software Configuration Management (SCM) environments are implemented as a loose set of tools to be combined. They differ with each installation. There is no platform independent technology to combine such tools and libraries under one company defined framework and development process model. Most of the time, the source code handling and control is separate from the compile (build) logic and other tools used. In addition, the source control libraries available maintain their own private format so that a user must perform check-outs and check-ins with regard to a file system. On the other side, the developers always prefer to work with the file system view because there they have the most tools available and it is transparent for the developer. They prefer to do edit, compile (one form of a build), and debug operations with the look and feel of a file system, but also preferably want in the background to have all the advantages of a source control library to enable a team development structure.
One problem of the prior art systems consists of the fact that the known implementations provide proprietary implementations which lack compatibility with other systems. There exist elements on the way to a solution of this problem, but such elements do not provide an open and platform independent definition which enables a unique platform for the use of different operating systems, library implementations and tools. An example of a known system using a declarative approach is represented by the IBM product called “Software Configuration and Library Manager (SCLM),” which is part of the IBM OS/390 operating system family and is described in the IBM publication “Software Configuration and Library Manager (SCLM) Project Manager's Guide,” OS/390 Version 2, Release 5.0, publication no. SG28-1319-02, 1998, the disclosure of which is incorporated by reference herein. This product uses proprietary definitions for the elements controlled in a library system and for the functions provided, but it does not provide support for any library system and any operating system. It lacks however a built-in process flow support.
Another known system is represented by a product called “TeamConnection,” which is described in the IBM publication “Getting Started with the TeamConnection Clients, Version 3.0,” publication no. SC34-4552-02, 1998, the disclosure of which is incorporated by reference herein. “TeamConnection” does not use the declarative approach but contains certain functional elements like tracking approaches, data security and notification. Also, this system does not provide a platform independent support.
Besides, in the known environments, the developers work on a file system to do their jobs and just once in awhile they are interested in synchronizing their source with the back end library system to get the files saved and to update the library system to serve as a base for a common driver. However, the builds are not ensured to be common across all users and back end processes.
Companies which are creating software products for their own business, or selling such products, need a development environment which ensures the following of defined rules and processes for different purposes such as security, quality, reliability and legal subjects, and supports any needed technology. None of the known products allow covering all the technologies and processes needed. However, it would be highly advantageous for existing tools and products, with their functions and processes, to be built into a defined framework to integrate them into one well-defined solution.